pingで何が確認できるのか検証してみた

はじめに

こんにちは、AWS事業本部のニシヤマです。はいマスキュラー。

よくPCから特定のサーバや、連携する別システムなどとの疎通確認にpingコマンドを使うかと思います。 先日、管理外のノードに対して疎通確認を行った際にpingで何が確認できているのかがふんわりとしかわかってなかったので試してみました。

Wikipediaのページを見ると十分な気もしますが一応自分でも確認してみます。

pingとは？

Wikipediaより

ping（ピン、 ピング[1]）はIPネットワークにおいて、ノードの到達性を確認するためのソフトウェアである。

pingはTCP/IPモデルのインターネット層に属するICMP（Internet Control Message Protocol）の「エコー要求(Echo Request)」と、「エコー応答（Echo Reply）」を利用しています。 また、ICMPはTCP、UDPと同じトランスポート層のプロトコルですが、IP（Internet Protocol）と同じインターネット層のプロトコルと同じ様な振る舞いをするとのことです。ここはあまり意識してなかったのですがまた調べて見ようと思います。

試してみる

以下の環境を用意します。管理外の環境との通信を想定して異なるVPCでVPCピアリングを行います。 各VPCには1台づつのEC2を立ち上げ（Instance-A、Instance-B）SSHでログインできる様にしておきます。

VPCの設定は以下になります。

まずはpingが通る環境にするためお互いのルートテーブルに対向VPCのセグメントを指定します。また、セキュリティグループで対向VPCのセグメントから「すべての ICMP」を許可しておきます。

Instance-Aのセキュリティグループ

Instance-Bのセキュリティグループ

pingしてみる

両方のEC2（Amazon Linux 2）にSSHログインしお互いのプライベートIPアドレスにpingしてみます。

Instance-AからInstance-Bにping

[ec2-user@instance-a ~]$ ping 10.2.120.72
PING 10.2.120.72 (10.2.120.72) 56(84) bytes of data.
64 bytes from 10.2.120.72: icmp_seq=1 ttl=255 time=0.464 ms
64 bytes from 10.2.120.72: icmp_seq=2 ttl=255 time=0.565 ms
64 bytes from 10.2.120.72: icmp_seq=3 ttl=255 time=0.496 ms
^C
--- 10.2.120.72 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2036ms
rtt min/avg/max/mdev = 0.464/0.508/0.565/0.046 ms

Instance-BからInstance-Aにping

[ec2-user@instance-b ~]$ ping 10.1.15.180
PING 10.1.15.180 (10.1.15.180) 56(84) bytes of data.
64 bytes from 10.1.15.180: icmp_seq=1 ttl=255 time=0.445 ms
64 bytes from 10.1.15.180: icmp_seq=2 ttl=255 time=0.439 ms
^C
--- 10.1.15.180 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1011ms
rtt min/avg/max/mdev = 0.439/0.442/0.445/0.003 ms

双方問題なくpingが通ります。

検証

ルートテーブルの検証

では、次にVPC-B側のルートテーブルrtb-Bのルート情報を削除してpingを実行してみます。

Instance-AからInstance-Bにping

[ec2-user@instance-a ~]$ ping 10.2.120.72
PING 10.2.120.72 (10.2.120.72) 56(84) bytes of data.
^C
--- 10.2.120.72 ping statistics ---
13 packets transmitted, 0 received, 100% packet loss, time 12288ms

Instance-BからInstance-Aにping

[ec2-user@instance-b ~]$ ping 10.1.15.180
PING 10.1.15.180 (10.1.15.180) 56(84) bytes of data.
^C
--- 10.1.15.180 ping statistics ---
21 packets transmitted, 0 received, 100% packet loss, time 20466ms

ルート情報を削除したVPC-B側のInstance-BからInstance-Aにpingが通らないのはもちろん、Instance-Aからのpingもレスポンスがなくなり、双方「100% packet loss」との表示になります。

再度、ルート情報を追記して双方pingが通る状態を再現します。

セキュリティグループの検証

今度はInstance-Bに関連付けられたセキュリティグループのルールを変更削除すると、Instance-Aからのpingが通らなくなります。

Instance-Bに関連付けられたセキュリティグループをカスタム ICMP ルールでプロトコルを変えながら試したところ、タイプが「すべての ICMP」でプロトコルが「すべて」または「エコー要求(Echo Request)」を許可した場合と、タイプ「すべてのトラフィック」を許可した場合にpingが通りました。

ネットワーク ACLの検証

今度はVPC-Bのネットワーク ACLでアウトバウンドで「エコー応答（Echo Reply）」のみDenyにしてみたところ、Instance-BからInstance-Aにpingは通りますが、Instance-AからInstance-Bにpingが通らなくなりました。

もちろん、ping送信側のVPC-Bからのアウトバウンドで「エコー要求(Echo Request)」をDenyにしてもpingが通らなくなりました。

まとめ

上記の試してみた結果からpingが通る時は以下の条件の確認ができることがわかりました。

• ping送信元、ping送信先双方のルート情報が正しく設定されている
• ping送信先のインバウンドで「エコー要求(Echo Request)」が許可されている
• ping送信先のアウトバウンドで「エコー応答（Echo Reply）」が許可されている

ICMPの特定のプロトコルのみ制御しているケースは少ないかと思いますが、今後のネットワークのトラブルシューティングの際にpingのレスポンスが無い場合には上記の点をチェックしていくことでより問題箇所が特定できるようになるのではないかと思います。

おまけ（最近の格闘技）

少し時間が経ってしまいましたが、5月前半は本当にMMAの大会が多かったです。 11日の夜にはOneFCでキックボクシングや、ムエタイで激しい試合が多く日本の修斗のチャンピオン佐藤将光選手が存在感を出していましたね。 そのまま数時間後の12日の早朝からはBellatorとUFC237が同じ時間にやっており、テレビとスマートフォンを利用しながら両方を見るという暴挙に出てしまいました。Bellatorでもいくつもすごい終わり方の試合がありましたが、UFCメインイベントの女子ストロー級タイトルマッチは本当に衝撃的な終わり方で唖然としてしまい本当になんて日だ！です。 その後、午後は日本のMMA団体DEEP2001のイベントを見に行き、その日は興奮しっぱなしの忙しい一日になりました。 17日には青木真也選手がOneFCでタイトルマッチ防衛戦で日本の視聴者を盛り上げてくれ、また昨日はUFCがありイベントには事欠きませんでした。 令和になって早々毎週MMAイベントを見てたので5月後半はのんびりしたいと思います。

ただ、6月2日にはRIZIN.16が神戸であり急遽観戦することになったので初RIZIN生観戦が今から楽しみです！6月も楽しみなMMAイベントてんこ盛りなので来月もこんな感じで行きたいと思います。